1. Field of the Invention
Embodiments of the present invention relate to establishing and maintaining a map of relationships among entities in a distributed architecture peer-to-peer enterprise information system network.
2. Related Art
Typically source systems, such as databases (DBs), web servers etc., of an enterprise information system (EIS) have been used for storing and maintaining information. This information may be stored and maintained in the source systems by associating the information with data types. For example, referring to Prior Art FIG. 1, Human Resources (HR) user 122, email user 142, and employee record 132 are examples of data types for which information (values for 124, 126, 144, 134, 136, 138) is stored and maintained in source systems 110. More specifically, HR user 122 may be used for storing and maintaining the first name 124 and last name 126 of a person. Similarly, an email user 142 may be used for storing and maintaining the email address 144 of a person, while an employee record 132 may be used for storing and maintaining the first name 134, last name 136, and email address 138 for a person.
The data types may be stored and maintained in separate source systems 110. For example, the information associated with the HR user 122 may be stored and maintained in a database (HR DB) 120 while the information associated with the email user 142 may be stored and maintained in an email DB 140. Similarly, the information associated with employee record 132 may be stored and maintained in a payroll database (DB) 130.
The modification of information associated with particular data types may impact information associated with other data types, thus, the information in the different data types which may reside in different source systems 110 may need to be synchronized. For example, an instance of HR user 122 in HR DB 120, an instance of employee record 132 in payroll DB 130, and an instance of email user 142 in email DB 140 may all store information for a particular person. In this case, if the last name 126 of the HR user 122 is modified from “Jones” to “Smith,” for example, the employee record 132 and the email user 142 for the particular person may also need to be modified to reflect the change in name (referred to hereinafter as “synchronization”).
Prior Art FIG. 1 depicts one prior art approach to synchronizing information associated with various data types using a centralized server 170. Novell Dir XML, SunONE Metadirectory 5, IBM Directory Integrator, WebMethods, SunONE Integration Server, and BEA Weblogic Integration are examples of products that provide synchronization and consolidation of information that is stored and maintained in different source systems using a centralized server architecture similar to that depicted in FIG. 1.
In a centralized server architecture, modified information is communicated from the source systems 110 that store and maintain information to the centralized server 170 using connector views 150, which are associated with the source systems 110, to the combiner 160. The combiner 160 determines what data types may be impacted by modified information. Centralized server 170 stores and maintains information for all of the data types from all of the source systems 110 associated with the enterprise information system 100; thus, centralized server 170 may be used for providing a “metaview,” e.g., consolidated view, for all the information that is stored and maintained in the source systems 110.
Continuing the example, although HR DB 120 may have an instance of the HR user 122, payroll DB 130 may have an instance of employee record 132, and email DB 140 may have an instance of email user 142 for the particular person, the centralized server 170 may also have values for the union of attributes (e.g., first name, last name, email address) for the particular person. Assuming, that HR DB 120 only includes an instance of HR user 122, payroll DB 130 only includes an instance of employee record 132, and email DB 140 only includes an instance of email user 142 for the particular person, then the “metaview” may include the value (e.g., “Jane”) of first name 172, the value (e.g., “Jones”) of last name 174, and the value (e.g., “Jane.Jones@sun.com”) of the email address 176 for the particular person, thus, the “metaview” provides a way of seeing all the information that is stored and maintained in the source systems 110.
When modified information is communicated to the centralized server 170, the information is stored in the centralized server 170 and communicated back to the source systems 110, which may need to synchronize the information based on the modification. The information may be communicated from the centralized server 170 to the source systems 110 through the combiner 160 and the connector views 150.
Continuing the example of a particular person's last name being modified from “Jones” to “Smith,” the last name 126, LN 136, and last name 174 may need to be updated for the particular person in the source systems 110 and the centralized server 170. Similarly, assuming that email address is formed, for example, as a concatenation of “first name,” “.”, “last name,” and “@sun.com,” the values of the email addresses (138, 144) associated with the email user 140 and employee record 132 may also need to be updated in the source systems 110 and the centralized server 170.
In this case, assume that the last name 126 of HR user 122, which is stored in HR DB 120, is first modified from “Jones” to “Smith.” The new value (e.g., “Smith”) for last name 126 may be communicated to the connector view CV1, which is associated with HR DB 120. CV 1 in turn communicates the new value to the combiner 160, which determines that the employee record 130 and the email user 140 may be impacted. The old value (e.g., “Wright”) for the last name 174 in centralized server 170 is replaced with the new value (e.g., “Smith”) for the last name 126 of HR user 122. Similarly, the value of email address 176 is also modified in the centralized server 170.
Although the centralized server 170's information (172, 176) has been synchronized, the source system 110's information (136, 138, 144) has not been synchronized yet. Thus, the modifications to last name 174 and email address 176 are communicated from the centralized server 170 to the combiner 160. The combiner 160 communicates the modifications to the last name 174 and email address 176 to the connector view CV2, which communicates the modifications to payroll DB 130. Payroll DB 130 updates the instance of employee record 132 based on the modifications it receives. Similarly, combiner 160 communicates the modifications of the email address 176 to the connector view CV3, which communicates the modifications to email DB 140. Email DB updates the instance of email user 142 based on the modifications it receives. After all of the synchronizations have been performed, last name 126, LN 136, and last name 179 are set to the value “Smith.” Similarly, email address 138, email address 144, and email address 176 are set to the value “Jane.Smith@sun.com.”
The centralized server approach of the prior art has numerous disadvantages. For example, the centralized server 170 becomes a performance bottle-neck as all modifications to information that is stored and maintained in source systems 110 must be communicated to the centralized server 170 in order to perform data synchronization and consolidation. Further, the centralized server architecture of Prior Art FIG. 1 cannot be scaled horizontally e.g., by adding additional server systems. Instead, the centralized server architecture can only be scaled vertically e.g., by increasing the power of the server system that executes the centralized server 170.
Also, synchronization between sources is made difficult because common information may be organized differently between the different sources. The data types may have different names, different data organizations, etc. from one source to another.